Automating the life cycle of a distributed Computing application

ABSTRACT

A system for automating the life cycle of a software application is provided. The software application utilizes computing resources distributed over a network. A representative system includes creating logic operable to create a task list which describes how at least one stage in the application life cycle is to be performed, and processing logic responsive to the creating logic, operable to process the task list to perform at least one stage in the application life cycle. The processing logic is integrated with a development environment, and the development environment is used to develop the software application.

FIELD OF THE INVENTION

[0001] The present invention relates generally to distributed computingsoftware, and more particularly to tools used to develop and builddistributed computing software.

DESCRIPTION OF THE RELATED ART

[0002] For many years, scientists, academics and engineers have usedcomputers to solve complex problems. Computers are used, in manydifferent disciplines, for tasks such as modeling, simulation andforecasting. For example, the scientific community has used suchnetworks to sequence genes, analyze astronomic data and analyze weatherforecast data. Because these tasks are computationally complex and/orinvolve huge amounts of data, high-performance computers are generallyused, and many interesting problems are not investigated because accessto such high-performance computers is very limited.

[0003] A relatively new approach to complex computing relies on theaggregate computing power of networks of computers instead of individualhigh-performance computers. These networks are known as “computationalgrids”, or simply “grids,” while the computers on the grid are called“grid nodes.” The infrastructure of these computational grids isdesigned to provide consistent, dependable, pervasive and inexpensiveaccess to computing resources, which in the aggregate provide highperformance computing capabilities.

[0004] To take advantage of computational grids, a computing task isdecomposed so that it runs in parallel on multiple grid nodes. Somecomputing tasks are suited for data decomposition, where the sameapplication executes on many grid nodes in parallel using differentdata. Others are suited for task decomposition, where differentapplications execute on many grid nodes in parallel using the same data.Other forms of decomposition are also possible, as well as a combinationof multiple forms of decomposition.

[0005] Grid computing began in the academic and scientific community.The tools first used to develop applications for the grid were thereforethose familiar to academics and scientists, and were typically based onthe Unix operating system and the C programming language. These softwaredevelopers are comfortable with the “bare bones” development environmentprovided by Unix, with features such as command line interpreters, shellscripts, etc.

[0006] Grid computing is now beginning to spread to the businesscommunity. Software developers in the business community typically use adifferent set of tools and a different development environment. In orderto make grid computing more accessible to the wider business community,there is a need for systems and methods that address these and/or otherperceived shortcomings of the prior art.

SUMMARY OF THE INVENTION

[0007] One embodiment, among others, of the present invention providessystems and methods for automating the life cycle of a softwareapplication. The software application utilizes computing resourcesdistributed over a network. A representative system includes creatinglogic operable to create a task list which describes how at least onestage in the application life cycle is to be performed, and processinglogic responsive to the creating logic, operable to process the tasklist to perform at least one stage in the application life cycle. Theprocessing logic is integrated with a development environment, and thedevelopment environment is used to develop the software application.

[0008] One method, among others, includes: creating a task list whichdescribes how at least one stage in the life cycle is to be performed,and processing the task list by a process engine to perform at least onestage in the life cycle. The process engine is integrated with adevelopment environment, and the development environment is used todevelop the software application.

DESCRIPTION OF THE DRAWINGS

[0009]FIG. 1 is a block diagram of a network of distributed computingresources.

[0010]FIG. 2 is a block diagram of the software life cycle of a gridnode application from FIG. 1.

[0011]FIG. 3 is a diagram showing how some prior art performs stages inthe software life cycle of FIG. 2, using one or more grid clientprograms.

[0012]FIG. 4 is a block diagram illustrating one aspect of an embodimentof the system for automating the life cycle of a grid node application.

[0013]FIG. 5A is a diagram of one embodiment of a user interface for thesystem for automatiing the life cycle of a grid node application.

[0014]FIG. 5B is a diagram of the user interface after the processengine of FIG. 4 has performed an execution stage.

[0015]FIG. 6 is a block diagram of the software components that oneembodiment of the process engine of FIG. 4 uses to invoke grid servicesof FIG. 1.

[0016]FIG. 7 illustrates an example of an embodiment of a grid node ofFIG. 1.

DETAILED DESCRIPTION

[0017]FIG. 1 is a block diagram of a network of distributed computingresources 100. The network 100 consists of one or more computingresources 101 a-c in communication with each other through data network102 (connections to network not shown). As described above, this grid100 can be used to perform computing tasks which are typically verycomplex and/or involve a very large amount of data. The term “computingresources” includes many different types of resources, not justcomputers. Other examples include storage resources, file systems, anddatabases. In order to simplify the explanation of the invention, thecomputing resources described herein will be computers, but theprinciples of this invention apply to all types of computing resources.The network will be referred to hereinafter as the grid 100, computingresources will be referred to as grid nodes 101 a-d, and an applicationthat runs on a grid node to perform a computing task (or subtask, if thecomputing task has been decomposed) will be called a grid nodeapplication 103.

[0018] To execute a grid node application 103 on a grid node 101, nodeswhich can provide appropriate computing resources must first beidentified, and the grid node application 103 must be submitted to theidentified node(s) as a job for execution. Rather than using acentralized resource manager and/or job submission manager, the grid 100as it exists today uses a decentralized approach, where each grid nodegrid node 101 provides: grid services 104 which support resourcediscovery, job submission, and other functionality; and a grid client105 which uses the grid services 104 provided by other grid nodes 101.This can best be illustrated by an example.

[0019] In FIG. 1, grid node 101 a submits a grid node application 103for execution on grid node 101 b and grid node 101 c. This isaccomplished by grid client 105 a using the grid services 104 b providedby grid node 101 b (shown by path 106) and using the grid services 104 cprovided by grid node 101 c (shown by path 107). Grid node 101 a alsoexecutes another grid node application 103, using its own computingresources, on behalf of grid node 101 c. This is accomplished by gridclient 105 c using the grid services 104 a provided by grid node 101 a(shown by path 108).

[0020] In FIG. 1, grid client 105 is shown as a single entity whichcommunicates with the single entity grid services 104. Since gridservices 104 provides different types of services, in some embodimentsgrid services 104 may be implemented by multiple entities within gridnode 101. For example, the resource discovery functions could beimplemented by a grid resource service and the job submission functionscould be implemented by a job submission service. Similarly, in someembodiments, the grid client 105 may be implemented by separate gridclient utility programs executing on grid node 101. For example, aGrid-Info-Search client program could communicate with grid services 104to access resource discovery services and a Grid-Run client programcould communicate with grid services 104 to access job submissionservices.

[0021]FIG. 2 is a block diagram of the software life cycle 200 of a gridnode application 103. The life cycle 200 consists of multiple stages:development 201; packaging 202; distribution 203; installation 204;execution 205; collection 206; and cleanup 207. In the development stage201, the grid node application 103 is developed using applicationdevelopment tools, for example, an editor, a compiler and a Grid toolkit601 (FIG. 6).

[0022] In the packaging stage 202, the grid node application 103 ispackaged, so that all files required to run the application are packagedtogether. For example, an application written in Java may requireseveral different applets and classes in order to run, and thesecomponents can be aggregated into a single archive file. Packaging isoften used because it simplifies transfer of the application to anothersystem, but packaging stage 202 is not necessary.

[0023] In the distribution stage 203, grid node application 103 isdistributed to the target nodes where it will run. Distribution stage203 may involve the transfer of a single file (particularly if packagingis used) or it may involve transferring each required file individually.If a node requires additional installation after files are distributed,for example, setting up the run-time environment on the target nodes,then the installation stage 204 performs installation.

[0024] At the execution stage 205, grid node application 103 executes onthe target nodes. At the collection stage 206, the results from theexecution of the grid node application 103 on one or more target nodesare collected. At the uninstall stage 207, the grid node application 103is uninstalled, removing it from the target nodes.

[0025]FIG. 2 is intended as an illustration of a typical life cycle 200.However, some stages are optional, so that the life cycle 200 of aparticular grid node application 103 may not have all stages shown inFIG. 2. For example, the packaging stage 202 and the installation stageare often 203 unnecessary for a particular grid node application 103. Itis also possible for the life cycle 200 of a particular grid nodeapplication 103 to contain additional stages not shown in FIG. 2.

[0026] Life cycle 200 does not always progress from one stage to anotherin a strict sequence. Instead, it is common for a subset of stages inthe life cycle 200 to be repeated. For example, while the grid nodeapplication 103 is still under development, the development stage 201and packaging stage 202 may be repeated many times while the developerdebugs the grid node application 103, while the remaining stages are notrequired because the developer executes the grid node application 103locally rather than using the grid 100. As another example, whendevelopment is complete, the stages of distribution, execution andcollection may be repeated may times as the user runs the grid nodeapplication 103 on several different sets of target nodes.

[0027]FIG. 3 is a diagram showing how some prior art performs stages inlife cycle 200 using one or more grid client programs. Typically, thedevelopment stage 201 and the packaging 202 are performed with standardapplication development tools (e.g. compiler, editor, compressionutility, etc.) However, other stages are performed with one or more gridclient programs which use various grid services 104. (Alternatively, asexplained above, a single grid client 105, with access to all gridservices 104, could be used instead).

[0028] In the example shown in FIG. 3, stage 203 is the distributionstage. Grid-Proxy-Init 301 is a grid client 105 which obtainsauthenticated access to the grid 100. Grid-Info-Search 302 is a gridclient 105 which invokes a query on the meta-information grid serviceprovided by grid services 104 to identify target nodes. Grid-Copy 303 isa grid client 105 which moves files between grid nodes 101. The filescan be data files, executable files, or a package file containing acombination of these.

[0029] Install stage 204 and Execute stage 205 both use Grid-Run 304 toexecute a specific program on the target nodes. Typically, the installstage 204 will execute shell commands or utility programs in order tocreate directories, move files, uncompress files, etc. Execute stage 205executes the grid node application 103.

[0030] Collect stage 204 is performed using Grid-Status 305, which is agrid client 105 which checks the status of a grid node application 103which was executed on a target node. Collect stage 204 also usesGrid-Copy 303 to copy output files produced by the execution of the gridnode application 103 on the target nodes. Uninstall stage 207 isperformed using Grid-Run 304, typically executing shell commands andutilities to delete files from the target nodes and restore environmentvariables and paths.

[0031] As discussed above, in the prior art approach described by FIG.3, a developer of a grid node application 103 performs some stages usingstandard software development tools and other stages using grid clientprograms 105. The developer may automate the stages to some degree byusing one or more shell scripts which invoke grid client programs 105and pass appropriate parameters to the programs. While this level ofautomation is preferable to manually invoking grid client programs 105from the command line, a shell script interpreter is a general purposetool which has no concept of stages in a life cycle, so that some degreeof expertise in scripting is required to achieve the desired result ofautomating the life cycle of a grid node application 103.

[0032]FIG. 4 is a block diagram illustrating one aspect of an embodimentof the system for automating the life cycle of a grid node application400. Process engine 401 performs the tasks associated with one or morestages in life cycle 200 of a particular grid node application 103. Thelife cycle 200 is described in input file 402, which is a text file.Each stage in life cycle 200 corresponds to a section 403 a-d in inputfile 402. Each section 403 a-d consists of a task list 404 a-d, which isa list of tasks to be performed for that stage. Since input file 402 isa text file, it may be created and edited using any text editor.Alternatively, input file 402 could be created and/or modified by aprogram.

[0033] In one embodiment, process engine 401 does not perform the tasksitself, but relies on individual task subsystems 405 to perform eachtype of task. In FIG. 4, three types of tasks are performed (Grid-Run,Grid-Status, Grid-Copy) and thus three task subsystems 405 a-c areshown. In one embodiment, process engine 401 invokes appropriate gridclient utility programs to perform tasks. For example, the Grid-Run tasksubsystem 405 a of process engine 401 invokes the grid client utilityprogram Grid-Run (as discussed with regard to FIG. 3). In anotherembodiment, process engine 401 uses a toolkit (see FIG. 6) to accessgrid services 104.

[0034] Input file 402 may allow one stage to be specified as dependenton another stage. In FIG. 4, since an application cannot be distributedbefore it has been developed, section 403 b of input file 402 indicatesthat the distribution stage 203 is dependent on the development stage201. In one embodiment, a parameter indicates which stage(s) the processengine 401 is to perform, and if dependencies are present, then processengine 401 determines which, if any, other stages must be performedfirst.

[0035] In FIG. 4, the process engine 401 is directed (at 406) to performthe collect task 206. Section 403 d of input file 402 represents thecollection stage 206, and contains a task list 404 d with two tasks: oneto check the status of the submitted job; and another to transfer a filecontaining the results. Process engine 401 determines if grid nodeapplication 103 should be executed before results are collected. Thisdetermination could be made, for example, by checking for the presenceof the output files generated on a target node when grid nodeapplication 103 executes. If the output files are not present, then theexecution stage 205 should be performed before the collect stage 206.One skilled in the art will understand that process engine 401 couldemploy a variety of methods to determine dependencies.

[0036] Process engine 401 decides to perform (at 407) the task listassociated with execution stage 205. The Grid-Run task subsystem 405 aexecutes a grid node application 103 on one or more target nodes. Theparticular grid node application 103 and target nodes which are passedas parameters to grid services 104 could be specified directly in inputfile 402, or in another file referenced by input file 402.

[0037] At 408, process engine 401 decides to perform the task listassociated with collect stage 206. The Grid-Check-Status task subsystem405 b checks the status of a grid node application 103 on one or moretarget nodes. The Grid-Copy task subsystem 405 c copies files from oneor more target nodes to the node which submitted the grid nodeapplication 103 for execution. Processing by process engine 401 is thencomplete, as the last task in the collect stage 206 has been performed.

[0038] In one embodiment, the process engine 401 verifies thatpre-conditions are satisfied before performing a specific task in tasklist 404. Pre-conditions are specified at the task level, as parametersin input file 402. For example, if the distribution stage 203 includes atask which copies a file to a target grid node 101, preconditions forthat task may include: the source file exists; the target grid node 101exists, there is enough disk space on the target grid node 101, the userhas permissions to copy the file and to create and write the file to thetarget, etc.

[0039] Pre-conditions also allow process engine 401 to take into accountthe specific requirements of a particular grid node application 103 whenperforming a task. For example, a grid node application 103 may run onlyon an Intel® platform with a Linux® operating system, so a preconditionfor the Grid-Run task in this case verifies that the target grid node101. In one embodiment, the process engine 401 tests preconditionsiteratively on all available grid nodes 101 within a organization. Todetermine whether or not pre-conditions are satisfied for a particulargrid node 101, process engine 401 uses grid services 104 to obtainmeta-information about the resources available on grid node 101, andcompares this with the requirements of the grid node application 103.

[0040] While pre-conditions are defined at the task level, theresolution of pre-conditions is handled at the stage level and job level. That is, the section 403 of input file 402 which defines a stage alsospecifies how failure of a pre-condition is handled. For example, apre-condition for the collection stage 206 (which collects the resultsproduced by an executed job) would be that the submitted job hassuccessfully completed execution. If this pre-condition is not met, thenthe submitted job is aborted and/or resubmitted.

[0041]FIG. 5A is a diagram of one embodiment of a user interface for thesystem for automating the life cycle of a grid node application 400. Inthis embodiment, grid node application 103 is developed using anintegrated development environment 501. Integrated developmentenvironment 501 typically includes: a compiler for translatingindividual source files into object code or into interpreted byte code;a linker for combining multiple object code modules into an executableprogram; and an editor for creating and modifying source files.Integrated development environment 501 may include other tools. Theeditor in the integrated development environment 501 may be used to edittask lists 404 contained in input file 402. Process engine 401 isintegrated into integrated development environment 501, so that allstages in the life cycle 200 can be performed from within integrateddevelopment environment 501.

[0042] In this embodiment, the user interface for integrated developmentenvironment 501 consists of one window which is split into severalpanes: the project pane 502; the structure pane 503; the content pane504; and the message pane 505. The content pane 504 allows editing ofsource files. The structure pane 503 shows in a hierarchical form thestructure of the file that is currently displayed in content pane 504.The message pane 505 displays messages which result from variousoperations such as building, compiling, debugging and testing.

[0043] The life cycle stages described by input file 402 are displayedin project pane 502 as nodes 506 a-d. In FIG. 5, node 506 c(corresponding to execution stage 205) is selected, a menu 507 ofpossible actions for that node is displayed, and the menu item Make ischosen. This action invokes process engine 401 and directs processengine 401 to perform the execution stage 205 as described by input file402.

[0044]FIG. 5B is a diagram of the user interface after process engine401 has performed execution stage 205. The message pane 505 displays anystatus messages generated by the process engine 401.

[0045] In one embodiment, the integrated development environment 501 isBorland JBuilder®, the process engine 401 is Apache Ant™, and the inputfile 402 is an XML build file. In this embodiment, stages correspond toAnt™ targets, and the tasks are implemented as Java classes which extendthe base classes in Ant™.

[0046]FIG. 6 is a block diagram of the software components that oneembodiment of process engine 401 uses to invoke grid services 104. Thesoftware can be viewed as layered. Process engine 401 is developed usingan appropriate toolkit 601 a, b. Toolkits 601 a, b are language andframework-specific, for example, toolkit 601 a is used to developgrid-aware applications in Java while toolkit 601 b is used to developgrid-aware applications with Common Object Request Broker Architecture(CORBA). In one embodiment, the toolkit is provided by the Globus JavaCommodity Grid Kit (Java CoG).

[0047] The Process engine 401 invokes grid services 104 through whateverapplication programming interface (API) is provided by the toolkit. Gridclient 105 presents an interface, API 602. Each toolkit 601 uses theGRID client API 602 to programmatically call grid client 105. Gridclient 105 uses GRID protocols 603 to communicate (over data network102) with the grid services 104 residing on another grid node 101.

[0048]FIG. 7 illustrates an example of an embodiment of a grid node 101of FIG. 1.

[0049] Generally, in terms of hardware architecture, the grid node 101is a general purpose computer including a processor 701, memory 702, andone or more input and/or output (I/O) devices or peripherals 703 thatare communicatively coupled via a local interface 704. The localinterface 704 can be, for example but not limited to, one or more busesor other wired or wireless connections, as is known in the art. Thelocal interface 704 may have additional elements (omitted forsimplicity), such as controllers, buffers, drivers, repeaters, andreceivers, to enable communications. Further, the local interface 704may include address, control, and/or data connections to enableappropriate communications among the aforementioned components.

[0050] The peripherals 703 may include input devices, for example butnot limited to, a keyboard, mouse, scanner, microphone, etc.Furthermore, the peripherals 703 may also include output devices, forexample but not limited to, a printer, display, etc. Finally, theperipherals 703 may further include devices that communicate both inputsand outputs, for instance but not limited to, a modulator/demodulator(modem; for accessing another device, system, or network), a radiofrequency (RF) or other transceiver, a telephonic interface, a bridge, arouter, etc.

[0051] The processor 701 is a hardware device for executing software,particularly that stored in memory 702. The processor 701 can be anycustom made or commercially available processor, a central processingunit (CPU), an auxiliary processor among several processors associatedwith the grid node 101, a semiconductor based microprocessor (in theform of a microchip or chip set), a microprocessor, or generally anydevice for executing software instructions.

[0052] The memory 702 can include any one or combination of volatilememory elements (e.g., random access memory (RAM, such as DRAM, SRAM,SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive,tape, CDROM, etc.). Moreover, the memory 702 may incorporate electronic,magnetic, optical, and/or other types of storage media. Note that thememory 702 can have a distributed architecture, where various componentsare situated remote from one another, but can be accessed by theprocessor 701.

[0053] The software in memory 702 may include one or more separateprograms, each of which comprises an ordered listing of executableinstructions for implementing logical functions. In the example of FIG.7, the software in the memory 702 includes the system for automating thelife cycle of a distributed computing application 705, and a suitableoperating system 706. The operating system 706 essentially controls theexecution of other computer programs, such as the system for automatingthe life cycle of a grid node application 400, and provides scheduling,input-output control, file and data management, memory management, andcommunication control and related services.

[0054] The system for automating the life cycle of a grid nodeapplication 400 is a source program, executable program (object code),script, or any other entity comprising a set of instructions to beperformed. When a source program, then the program needs to betranslated via a compiler, assembler, interpreter, or the like, whichmay or may not be included within memory 702, so as to operate properlyin connection with the operating system 706.

[0055] If the grid node 101 is a PC, workstation, or the like, thesoftware in the memory 702 may further include a basic input outputsystem (BIOS) (omitted for simplicity). The BIOS is a set of essentialsoftware routines that initialize and test hardware at startup, startthe operating system 706, and support the transfer of data among thehardware devices. The BIOS is stored in ROM so that the BIOS can beexecuted when the grid node 101 is activated.

[0056] When the grid node 101 is in operation, the processor 701 isconfigured to execute software stored within the memory 702, tocommunicate data to and from the memory 702, and to generally controloperations of the grid node 101 pursuant to the software. The system forautomating the life cycle of a grid node application 400 and theoperating system 706, in whole or in part, but typically the latter, areread by the processor 701, perhaps buffered within the processor 701,and then executed.

[0057] When the system for automating the life cycle of a grid nodeapplication 400 is implemented in software, it should be noted that thesystem for automating the life cycle of a grid node application 400 canbe stored on any computer readable medium for use by or in connectionwith any computer related system or computer readable medium. In thecontext of this document, a “computer-readable medium” can be any meansthat can store, communicate, propagate, or transport the program for useby or in connection with the instruction execution system, system, ordevice. The computer-readable medium can be, for example but not limitedto, an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, system, device, or propagation medium. Anonexhaustive example set of the computer-readable medium would includethe following: an electrical connection having one or more wires, aportable computer diskette, a random access memory (RAM), a read-onlymemory (ROM), an erasable programmable read-only memory (EPROM, EEPROM,or Flash memory), and a portable compact disc read-only memory (CDROM).Note that the computer-readable medium could even be paper or anothersuitable medium upon which the program is printed, as the program can beelectronically captured, via for instance optical scanning of the paperor other medium, then compiled, interpreted or otherwise processed in asuitable manner if necessary, and then stored in a computer memory.

[0058] In an alternative embodiment, where the system for automating thelife cycle of a grid node application 400 is implemented in hardware,the system for automating the life cycle of a grid node application 400can be implemented with any or a combination of the followingtechnologies, which are each well known in the art: a discrete logiccircuit(s) having logic gates for implementing logic functions upon datasignals, an application specific integrated circuit(s) (ASIC) havingappropriate combinatorial logic gates, a programmable gate array(s)(PGA), a field programmable gate array(s) (FPGA), etc.

[0059]FIG. 8 is a flow chart of a method of automating the life cycle ofa distributed computing application 800. At step 801, a grid nodeapplication 103 is developed using integrated development environment501. At step 802, a task list 404 describing the life cycle 200 of gridnode application 103 is created. The task list can be created in astand-alone editor, or an editor which is integrated into integrateddevelopment environment 501, or a program which automatically generatesthe task list based on user input, or any other suitable mechanism. Atstep 803, Process engine 401 processes the task list 404 to perform oneor more stages in life cycle 200.

[0060] The foregoing description has been presented for purposes ofillustration and description. It is not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Obviousmodifications or variations are possible in light of the aboveteachings. The embodiments discussed, however, were chosen and describedto illustrate the principles of the invention and its practicalapplication to thereby enable one of ordinary skill in the art toutilize the invention in various embodiments and with variousmodifications as are suited to the particular use contemplated. All suchmodifications and variation are within the scope of the invention asdetermined by the appended claims when interpreted in accordance withthe breadth to which they are fairly and legally entitled.

Therefore, having thus described the invention, at least the followingis claimed:
 1. A computer readable medium having a program forautomating the life cycle of a software application, where the softwareapplication utilizes computing resources distributed over a network, theprogram comprising logic configured to perform the steps of: creating atask list which describes how at least one stage in the life cycle is tobe performed; and processing the task list by a process engine toperform at least one stage in the life cycle, wherein the process engineis integrated with a development environment, where the developmentenvironment is used to develop the software application.
 2. The computerreadable medium of claim 1, wherein the development environment is anintegrated development environment.
 3. The computer readable medium ofclaim 2, wherein the integrated development environment includesJBuilder.
 4. The computer readable medium of claim 1, wherein theprocess engine includes Ant.
 5. The computer readable medium of claim 1,wherein the software application utilizes computing resources throughservice providers connected to the network.
 6. The computer readablemedium of claim 1, wherein the task list is stored in a text file. 7.The computer readable medium of claim 6, wherein the text file is an XMLfile.
 8. The computer readable medium of claim 1, wherein the task listincludes a first task, wherein the first task packages into a singlefile all files needed to run the software application.
 9. The computerreadable medium of claim 1, wherein the task list includes a secondtask, wherein the second task distributes the software application to atleast one remote computing resource.
 10. The computer readable medium ofclaim 1, wherein the task list includes a third task, wherein the thirdtask executes the software application on at least one remote computingresource.
 11. The computer readable medium of claim 1, wherein the tasklist includes a fourth task, wherein the fourth task collects resultsfrom at least one remote computing resource.
 12. The computer readablemedium of claim 1, wherein the task list includes a fifth task, whereinthe fifth task removes the software application from at least one remotecomputing resource.
 13. A system for automating the life cycle of asoftware application, where the software application utilizes computingresources distributed over a network, the system comprising: a task listeditor configured to create a task list, where the task list describeshow at least one step in the life cycle is to be executed; and a processengine operating on the task list to perform the at least one step inthe life cycle.
 14. The system of claim 13, further comprising: adevelopment environment for developing the software application, wherethe process engine is integrated with the development environment. 15.The system of claim 14, wherein the development environment is anintegrated development environment.
 16. The system of claim 13, whereinthe process engine is Ant.
 17. The system of claim 13, wherein thesoftware application utilizes computing resources through serviceproviders connected to the network.
 18. The system of claim 13, whereinthe task list is stored in a text file.
 19. The system of claim 18wherein the text file is an XML file.
 20. The system of claim 13,wherein the task list includes a first task, wherein the first taskpackages into a single file all files needed to run the softwareapplication.
 21. The system of claim 13, wherein the task list includesa second task, wherein the second task distributes the softwareapplication to at least one remote computing resource.
 22. The system ofclaim 13, wherein the task list includes a third task, wherein the thirdtask executes the software application on at least one remote computingresource.
 23. The system of claim 13, wherein the task list includes afourth task, wherein the fourth task collects results from at least oneremote computing resource.
 24. The system of claim 13, wherein the tasklist includes a fifth task, wherein the fifth task removes the softwareapplication from at least one remote computing resource.
 25. A systemfor automating the life cycle of a software application, where thesoftware application utilizes computing resources distributed over anetwork, the system comprising: creating logic operable to create a tasklist which describes how at least one stage in the application lifecycle is to be performed; and processing logic responsive to thecreating logic, operable to process the task list to perform at leastone stage in the application life cycle, wherein the processing logic isintegrated with a development environment, wherein the developmentenvironment is used to develop the software application.
 26. The systemof claim 25, wherein the development environment is an integrateddevelopment environment.
 27. The system of claim 25, wherein the processengine is Ant.
 28. The system of claim 25, wherein the softwareapplication utilizes computing resources through service providersconnected to the network.
 29. The system of claim 25, wherein the tasklist is stored in a text file.
 30. The system of claim 25, wherein thetext file is an XML file.